A Proposed Checklist for Building Complex Coupled Models

Coupled problems occur widely in the pure and applied sciences and engineering. Two types of models are becoming more common—multiscale models, which couple physical phenomena operating on different spatiotemporal scales, and multiphysics models, which couple distinct natural phenomena. The modelling of coupled systems is an emerging discipline that is now the focus workshops and conferences. Many groups have created model coupling software, spanning a spectrum ranging from custom-made, problem-specific solutions and application domain-specific frameworks to opensource and commercial generic coupling infrastructure packages. Constructing complex coupled models from numerous interacting models—or constituents—can be notoriously difficult. Coupled models exhibit knowledge, software, and algorithmic / computational complexity. Interdisciplinary teams are the mechanism used to master knowledge complexity. But how does one grapple with the other two types of complexity? Current practice is an ad hoc approach in which an interdisciplinary group achieves their goal by “just figuring it out” (JFIO). The problem with JFIO is it often begins with a team feeling thwarted and overwhelmed, proceeds without a clear roadmap, entails generous amounts of trial-and-error, and is prone to surprises that can cause delays. Furthermore, in software engineering terms JFIO is of low-level process maturity (e.g., not reproducible). Coupled systems thus far built typically have relatively few (∼ 5− 10) constituents. Any attempt to tackle more complex system modelling exercises such as coupling climate to energy and economics models or simulating a whole organism like the human body will require coupling of a significantly larger number of constituents. It is doubtful that JFIO will scale to meet such a challenge. Ideally, one would like a “cook book” approach to building a coupled model. In response to this desideratum I propose a methodology comprising a series of exercises and associated questions whose object is to define the requirements for a software implementation of a coupled system. This approach is distilled from years of experience as one of the software architects for the coupling infrastructure for the Community Climate SystemModel (CCSM; http://ccsm.ucar.edu) and my involvement in scientific community software framework projects such as the Earth SystemModeling Framework (ESMF; http://www.esmf.ucar.edu), the Common Component Architecture (CCA; http://www.cca-forum.org), and Framework Application for Core-EdgeTransport Simulation (FACETS; http://facetsproject.org). This analysis technique is also drawn from my own theoretical work on coupled models in which I have devised terminology, notation, and complexity metrics. I review previous theoretical work on coupling that is relevant to the exercises outlined in this paper. I then propose a checklist to guide a developer through the requirements-gathering and early design processes for a coupled model. This checklist comprises a series of exercises to identify properties of the envisioned coupled system and to identify and analyse its couplings, elucidating their input/output relationships, types, frequency, and estimated overhead imposed on the constituents. The checklist also covers commonly encountered software engineering issues. This is a proposed checklist: The set of exercises and questions may not fit a given problem perfectly; I encourage the reader to extend, prune, or modify them as necessary. I discuss in brief how distributed-memory parallelism (DMP) complicates this analysis. I offer the reader some advice on how the exercises need to be modified for application to DMP. I conclude that the approach is usable for situations in which coupling occurs in a single address space, but under DMP may become sufficiently laborious that automation may be required. 18th World IMACS / MODSIM Congress, Cairns, Australia 13-17 July 2009 http://mssanz.org.au/modsim09